人間の開発者は「何を」「なぜ」作るかに集中し、AIパートナーが「どのように」作るかを支援する。完璧なプロセスではなく、実践的で改善可能なワークフローとして、段階的に導入し、チームと共に進化させる。
AIは魔法の杖ではなく、強力な補助ツールです。このプロセスの目的は「AIに何をさせるか」ではなく、「人間がより価値の高い仕事に集中できるか」です。プロセスに固執せず、速く価値を届けるという本質を常に見失わないようにします。
| 観点 | 従来のAI活用 | AIDD 1.0 |
|---|---|---|
| 導入対象 | コア機能から一気に導入 | 簡単な20%から段階的に |
| 仕様の作り方 | 常に詳細な仕様書 | 3段階から選択（軽量が基本） |
| AI生成方法 | 一括生成後に手直し | 対話的な共同作業 |
| 検証手法 | 複雑な多重検証 | 既存ツール活用（テスト中心） |
| 時間配分 | 理論値を前提 | 実測値ベース |
| 失敗時 | 明確な基準なし | 撤退基準を明記 |
Phase 1（導入初期・最初の1-2ヶ月）: まず簡単な20%から始める
以下のような定型的で失敗しても影響が小さいタスクから導入します：
Phase 2（習熟後・3ヶ月目以降）: 徐々にコア機能へ拡大
チームがプロセスに慣れ、AIの特性を理解してから：
理由: 失敗しても痛くない領域で学習曲線を登ることで、重要な機能を扱う際のリスクを最小化します。
すべての機能に重厚な仕様は不要です。タスクの複雑度に応じて選択します：
## 機能: お気に入りトグル追加
### 要件
- FocusPresetにisFavoriteフラグ（Bool）を追加
- UI: 星アイコンでトグル表示
- タップで状態反転＋永続化
### 成功条件
- [ ] テストでトグル動作を確認
- [ ] 永続化の確認
- [ ] UIが状態を正しく表示
### 補足
- アイコンは右寄せ配置
- お気に入りの上限なし
適用タスク: CRUD操作、単純なUI変更、プロパティ追加など
feature: FavoritePreset
description: ユーザーが特定のプリセットをお気に入りとしてマークする機能
requirements:
model:
- Add isFavorite: Bool to FocusPreset
- Default value: false
ui:
- Star icon toggle in preset list (right-aligned)
- Filled star when favorited, outline when not
behavior:
- Toggle updates model and persists to CoreData
- No limit on number of favorites
acceptance_tests:
- scenario: "User favorites a preset"
given: "Preset A with isFavorite=false"
when: "User taps star icon"
then:
- "isFavorite becomes true"
- "Changes persist after app restart"
- scenario: "User unfavorites a preset"
given: "Preset B with isFavorite=true"
when: "User taps star icon"
then: "isFavorite becomes false"
edge_cases:
- "Multiple rapid taps should not cause race condition"
- "Persistence failure should show user error message"
適用タスク: 複数のコンポーネントにまたがる機能、エラーハンドリングが必要な処理
{
"featureName": "AdvancedPresetFiltering",
"description": "複数条件によるプリセットの動的フィルタリング機能",
"logicalSteps": [...],
"testScenarios": [...],
"edgeCases": [...],
"performanceRequirements": {...},
"securityConsiderations": {...},
"rollbackStrategy": {...}
}
適用タスク: アーキテクチャレベルの変更、セキュリティ要件が厳しい機能、パフォーマンスクリティカルな実装
重要: 大半のタスクはLevel 1-2で十分です。Level 3は本当に必要な場合のみ使用します。
人間とAIが対話しながら段階的に仕様を明確化します。
プロセス:
人間が機能の概要を提示
「プリセットにお気に入り機能を追加したい」
AIが確認質問で曖昧さを解消
[AI] 「いくつか確認させてください：
1. お気に入りは単純なON/OFFですか？それとも星5段階評価ですか？
2. お気に入りのプリセットは、リストの上部に自動ソートしますか？
3. お気に入りの数に上限は必要ですか？」
人間が判断し、詳細を決定
[人間] 「単純なON/OFF。ソート機能は後で考える。上限なし」
AIが複数の設計案を提示
[AI] 「この機能には以下のアプローチがあります：
【A案】モデルにBoolフラグ追加
- メリット: シンプル、移行容易、パフォーマンス良好
- デメリット: 将来的な拡張性が低い
【B案】別テーブルで管理
- メリット: 将来的に評価やメモを追加しやすい
- デメリット: 実装コスト高、クエリが複雑化
【C案】タグシステムとして実装
- メリット: 他の分類にも応用可能
- デメリット: オーバーエンジニアリングの可能性
推奨: 現時点での要件ならA案が最適です」
人間が最終決定し、仕様レベルを選択
[人間] 「A案で。Level 1の自然言語仕様でいい」
AIが選択されたレベルの仕様を生成
インプット: 機能アイデア（自然言語）
アウトプット: 適切なレベルの仕様ドキュメント
所要時間（目安）: 10-30分（従来の仕様作成より若干長いが、設計の質が向上）
AIが作りながら、人間が随時軌道修正します。一度に全部作らず、段階的に進めます。
プロセス:
テストコード生成
[AI] 「まずテストコードを生成します」
→ （30秒後）テストコード提示
[人間] 「いいね。ただし、永続化失敗時のテストも追加して」
[AI] 「承知しました」
→ （20秒後）改善版提示
実装コード生成
[人間] 「OK、実装コードを生成して」
[AI] 「生成しました。以下の点を確認してください：
- CoreDataへの保存にtry-catchを使用
- エラー時はユーザーにアラート表示
- コメントで各処理の意図を明記しました」
UI統合
[AI] 「SwiftUIのViewにも統合しました。
アイコンの配置は右寄せにしていますが、左寄せの方がいいですか？」
[人間] 「右でいい。ただしアイコンサイズを少し大きくして」
[AI] 「修正しました」
生成コードの品質要件:
コード例:
// AI生成コード（コメント付き）
func toggleFavorite(preset: FocusPreset) {
// 状態を反転
preset.isFavorite.toggle()
// CoreDataに永続化（エラーハンドリング付き）
do {
try context.save()
// Optional: デバッグ用ログ（本番では削除可能）
#if DEBUG
Logger.debug("Favorite toggled: \(preset.id) -> \(preset.isFavorite)")
#endif
} catch {
// ユーザーに通知
showError("お気に入りの保存に失敗しました")
// ロールバック
preset.isFavorite.toggle()
}
}
インプット: 仕様ドキュメント（Phase 1の成果物）
アウトプット:
所要時間（目安）:
既存のベストプラクティス（テスト、Linter）を活用し、過度に複雑化しません。
検証項目:
コンパイルチェック
テスト実行
静的解析
（Optional）AIコードレビュー
[AI自動レビュー結果]
✓ テスト全てパス
✓ スタイルガイド準拠
⚠ 注意: toggleFavorite()でのエラーハンドリング
→ 現状はアラート表示のみ。ログ記録も検討してください
ℹ 提案: お気に入り数の取得関数も追加すると便利かもしれません
重要: 構造化ログによる複雑な検証は行いません。テストが振る舞いを保証します。
インプット: 生成コード一式
アウトプット: 簡潔な検証レポート
所要時間（目安）: 自動実行（1-5分）
人間は受動的にレポートを確認するのではなく、能動的に3つの問いに答えます。
問1: 仕様は本当に正しかったか？（最重要・5分）
検証が全て緑でも、仕様自体が間違っていたら意味がありません。
自問すべき質問：
問2: AIの実装は受け入れ可能か？（5-15分）
確認項目：
必要に応じて部分的にコードをレビューします。全体を精読する必要はありません。
問3: 学びを次に活かせるか？（3分）
記録すべき内容：
インプット: 検証レポート、生成コード、仕様ドキュメント
アウトプット:
所要時間（目安）: 15-30分
理論値ではなく、実測データに基づいて改善します。
Week 1: ベースライン計測（従来手法）
機能A: プリセット編集機能の追加
- 仕様作成: 2時間
- 実装: 8時間
- デバッグ: 1時間
- レビュー: 1時間
合計: 12時間
Week 2: AIDD導入（同等の複雑度の機能B）
機能B: お気に入り機能の追加
- 仕様作成: 3時間（対話的なので従来より長い）
- AI生成: 30分
- 手直し・統合: 4時間
- 自動検証: 5分
- レビュー: 1時間
合計: 8.5時間
削減率: 29%（理論70%ではなく、実測値）
Week 4: プロセス最適化後（機能C）
機能C: フィルター機能の追加
- 仕様作成: 2時間（慣れて効率化）
- AI生成: 20分
- 手直し・統合: 2時間（プロンプトが洗練された）
- 自動検証: 5分
- レビュー: 30分
合計: 4.8時間
削減率: 60%（チームが習熟した結果）
チームで以下を継続的に計測し、ダッシュボード化します：
metrics:
efficiency:
- total_dev_time: "機能ごとの開発時間"
- ai_generation_time: "AI生成にかかった時間"
- human_adjustment_time: "人間の手直し時間"
- time_reduction_rate: "従来手法との比較"
quality:
- test_coverage: "テストカバレッジ"
- bug_count_in_production: "本番環境でのバグ件数"
- code_review_cycles: "レビューの往復回数"
satisfaction:
- developer_satisfaction: "開発者の満足度（5段階）"
- process_friction_points: "プロセスの摩擦点"
重要: 最初の数週間は効率が下がる可能性があります。学習曲線を考慮し、少なくとも1ヶ月は測定を続けます。
プロセスに固執せず、柔軟に対応します。
If AIの生成コードが30分以上の手直しを要する場合:
→ 従来手法に切り替え（無理にAIDDを続けない）
→ 後で「なぜAIがうまくいかなかったか」を分析
→ プロンプトや仕様の改善に活かす
If 仕様作成に予想以上の時間がかかっている場合:
→ より軽量な仕様レベルに格下げ
→ Level 2 → Level 1
→ 完璧な仕様ではなく「動くもの優先」に切り替え
If テストが通らず、30分以上デバッグしても解決しない場合:
→ AIにデバッグログを渡してトラブルシューティングを依頼
→ それでも解決しない場合は人間が直接コードを書く
→ 「AIに任せられない種類のタスク」として記録
哲学: AIは強力だが万能ではありません。うまくいかない時は素直に従来手法に戻り、そこから学びます。
目標: プロセス全体を1回通してみる
成功指標:
目標: チームに合わせてカスタマイズ
成功指標:
目標: より複雑な機能に適用開始
成功指標:
目標: プロセスを自動化・標準化
成功指標:
specification:
lightweight: "Markdown in GitHub Issues/Linear"
structured: "Notion、Confluence"
ai_platform:
recommended: "Claude, ChatGPT, GitHub Copilot"
version_control:
required: "Git (GitHub、GitLab、Bitbucketなど)"
testing:
unit: "XCTest、Jest、Pytestなど"
integration: "プロジェクト依存"
ci_cd:
recommended: "GitHub Actions、GitLab CI、Bitrise"
metrics:
tracking: "Notion、Linear、Jira"
Q1: 全ての機能でAIDDを使うべきですか？
A: いいえ。以下の場合は従来手法の方が効率的です：
Q2: 仕様作成に時間がかかりすぎるのですが？
A: 以下を試してください：
Q3: AIが生成したコードが使い物にならない場合は？
A: 以下を確認：
30分以上手直しするなら、従来手法に切り替えます。
Q4: 既存のコードベースにどう統合しますか？
A: 段階的に：
Q5: チーム全員が同じレベルでAIを使えない場合は？
A: ペアプログラミング方式で：
小さく始めて、段階的に拡大する
実測データを信じる
プロセスに固執しない
最後に: このプロセスは完成形ではありません。チームと共に進化させ、あなたのプロジェクトに最適化してください。数ヶ月後には、あなた独自の「AIDD 2.0」が生まれているはずです。
この区切り線以降のセクションは、あなた（AI）が読んで実行するための指示書です。
人間の開発者がこの文書を渡して「AIDDプロセスでサポートしてください」と言った場合、以下の手順に従ってプロセスを主導してください。
人間が「この文書のAIDDプロセスで開発したい」「この文書の内容でサポートして」などと言ったら、まずこのPhase 0を実行してください。
以下を1つのメッセージで質問してください：
AIDDプロセスを開始します！まず、プロジェクトについて教えてください：
1. **プロジェクト名**: 何を開発していますか？
2. **技術スタック**:
- 言語（Swift、Python、TypeScriptなど）
- フレームワーク（SwiftUI、React、Djangoなど）
3. **テスト環境**: 使用しているテストフレームワークは？（XCTest、Jest、Pytestなど）
4. **今回のアイデア**: どんな機能や改善を実現したいですか？（ざっくりでOKです）
これらの情報を元に、最適な開発プロセスを進めていきます！
人間の回答を受け取ったら、内部的に以下の形式でプロジェクトコンテキストを構築してください（人間には見せなくてOK）：
project_context:
name: [回答から抽出]
language: [回答から抽出]
framework: [回答から抽出]
testing: [回答から抽出]
current_idea: [回答から抽出]
complexity_level: [simple/medium/complex - あなたが判断]
プロジェクトコンテキストを構築したら、以下のメッセージでPhase 1を開始してください：
ありがとうございます！それでは、[機能名]の実装に向けて仕様を固めていきましょう。
Phase 1: 仕様作成を開始します。
まず、いくつか確認させてください：
[確認質問3-5個を生成]
人間のアイデアを構造化された仕様に変換します。対話を通じて曖昧さを解消し、最適な設計を提案します。
アイデアに対して3-5個の確認質問をしてください。以下の観点から：
1. [機能名]は[選択肢A]ですか？それとも[選択肢B]ですか？
2. [データ]はどこに保存しますか？（ローカル/サーバー/両方）
3. [エラー時]の挙動はどうしますか？
4. [上限や制約]は必要ですか？
5. UIは[配置案A]と[配置案B]、どちらが良いですか？
人間の回答を受け取ったら、3つの設計案を提示してください：
ありがとうございます！この機能には以下のアプローチがあります：
【A案】[シンプルなアプローチ]
- 実装方法: [具体的な方法]
- メリット: [箇条書き2-3個]
- デメリット: [箇条書き1-2個]
- 推奨度: ⭐⭐⭐⭐⭐
【B案】[柔軟性重視のアプローチ]
- 実装方法: [具体的な方法]
- メリット: [箇条書き2-3個]
- デメリット: [箇条書き1-2個]
- 推奨度: ⭐⭐⭐
【C案】[高機能なアプローチ]
- 実装方法: [具体的な方法]
- メリット: [箇条書き2-3個]
- デメリット: [箇条書き1-2個]
- 推奨度: ⭐⭐
**推奨**: 現時点の要件なら[A/B/C]案が最適です。理由は[簡潔に説明]。
どの案で進めますか？または、組み合わせや別のアイデアがあればお聞かせください。
選ばれた設計案の複雑度を判断し、適切な仕様レベルを選択してください：
Level 1（自然言語）を選ぶ条件:
- 単一のファイル/モデルへの変更
- エッジケースが少ない（2-3個以下）
- UIの変更が単純
- 例: プロパティ追加、ボタン追加、簡単なCRUD
Level 2（半構造化）を選ぶ条件:
- 複数のコンポーネントにまたがる
- エッジケースが中程度（4-6個）
- エラーハンドリングが必要
- 例: お気に入り機能、フィルター機能
Level 3（フルスペック）を選ぶ条件:
- アーキテクチャレベルの変更
- エッジケースが多い（7個以上）
- パフォーマンス/セキュリティ要件が厳しい
- 例: 認証システム、リアルタイム同期
原則: 迷ったらより軽量なレベルを選んでください。
選択されたレベルに応じて仕様を生成してください。
## 機能: [機能名]
### 要件
- [要件1: 具体的に]
- [要件2: 具体的に]
- [要件3: 具体的に]
### 振る舞い
- [ユーザーが〇〇すると、△△になる]
- [エラー時は□□する]
### 成功条件
- [ ] [テスト観点1]
- [ ] [テスト観点2]
- [ ] [テスト観点3]
### 補足
- [実装の注意点やUI配置など]
feature: [機能名]
description: [1-2文で説明]
requirements:
model:
- [モデルへの変更1]
- [モデルへの変更2]
ui:
- [UI要素1とその配置]
- [UI要素2とその配置]
behavior:
- [振る舞い1]
- [振る舞い2]
acceptance_tests:
- scenario: "[シナリオ名]"
given: "[前提条件]"
when: "[操作]"
then:
- "[期待される結果1]"
- "[期待される結果2]"
- scenario: "[エラーケース]"
given: "[前提条件]"
when: "[異常な操作]"
then: "[期待される結果]"
edge_cases:
- "[エッジケース1]"
- "[エッジケース2]"
implementation_notes:
- "[実装時の注意点]"
Level 2のYAMLを拡張し、以下を追加：
performance_requirements:
response_time: "[具体的な数値]"
memory_limit: "[具体的な数値]"
security_considerations:
- "[セキュリティ要件1]"
- "[セキュリティ要件2]"
rollback_strategy:
- "[ロールバック手順]"
logging_schema:
[構造化ログの定義]
生成した仕様を提示し、人間の承認を得てください：
仕様を作成しました！以下の内容でよろしいでしょうか？
[生成した仕様を表示]
---
✅ この仕様で問題なければ「OK」または「承認」とお伝えください。
🔧 修正が必要な箇所があれば、具体的にご指摘ください。
💡 別のアプローチを検討したい場合もお聞かせください。
承認されたら、Phase 2（コード生成）に進みます。
仕様に基づき、テストコード→実装コード→UI統合の順で段階的に生成します。各ステップで人間の承認を得ながら進めます。
まずテストコードのみを生成して提示してください：
Phase 2を開始します。まず、テストコードを生成しますね。
[テストコードを生成]
---
このテストコードで以下を検証します：
- ✅ [検証内容1]
- ✅ [検証内容2]
- ✅ [検証内容3]
問題なければ「OK」、修正希望があれば具体的にお伝えください。
承認されたら、実装コードを生成します。
acceptance_testsに基づく以下を必ず守ってください：
テストが承認されたら、実装コードを生成してください：
承知しました。次に実装コードを生成します。
[実装コードを生成]
---
実装のポイント：
- 📝 [実装で工夫した点1]
- 📝 [実装で工夫した点2]
- ⚠️ [注意が必要な箇所]
このコードで、先ほどのテストが全てパスするはずです。
問題なければ「OK」、質問や修正希望があればお伝えください。
requirementsとlogicalStepsに従うtry-catchで明示的に// AI生成コード例
// 機能: [機能名]
// 生成日: [日付]
/// [関数の説明]
/// - Parameter [パラメータ]: [説明]
/// - Returns: [戻り値の説明]
func functionName(parameter: Type) -> ReturnType {
// ステップ1: [何をするか]
let result = doSomething(parameter)
// ステップ2: [何をするか]
do {
try persistData(result)
// Optional: デバッグ用ログ
#if DEBUG
Logger.debug("Success: \(result)")
#endif
return result
} catch {
// エラーハンドリング
Logger.error("Failed: \(error)")
showError("操作に失敗しました")
throw error
}
}
実装が承認され、UI変更が必要な場合のみ実行：
最後に、UIへの統合コードを生成します。
[UIコードを生成]
---
UI実装のポイント：
- 🎨 [配置の説明]
- 🎨 [デザインの考慮点]
- ⚠️ [確認してほしい箇所]
アイコンの配置やサイズなど、調整したい点があればお伝えください。
全てのコードを生成したら、統合を確認：
コード生成が完了しました！
生成内容のまとめ：
✅ テストコード: [ファイル名]
✅ 実装コード: [ファイル名]
✅ UI統合: [ファイル名]
次のステップ：
1. これらのコードをプロジェクトに統合してください
2. テストを実行して、全てパスすることを確認してください
3. 結果を教えていただければ、Phase 3（検証）に進みます
何か問題や質問があればお聞かせください！
人間がテストを実行した結果を受け取り、問題があればトラブルシューティングを支援します。
人間がテスト結果を報告したら、以下のように応答してください：
素晴らしい！テストが全てパスしましたね 🎉
Phase 3の検証結果：
✅ コンパイル: SUCCESS
✅ テスト実行: 全てPASS
✅ 実装: 仕様通りに完了
Phase 4（最終レビュー）に進みましょう。
---
最終確認のポイント：
1. **仕様の妥当性**: この設計で後悔しないか？
2. **コードの品質**: パフォーマンス/セキュリティ上の懸念はないか？
3. **ユーザー体験**: 実際に使ってみて、違和感はないか？
これらを確認して、問題なければこの機能は完了です！
気になる点があればお聞かせください。
テストが失敗したんですね。一緒にデバッグしましょう。
エラー内容を教えてください：
- どのテストが失敗しましたか？
- エラーメッセージは？
- （あれば）スタックトレースやログ
情報をいただければ、原因を特定して修正案を提示します。
エラー情報を受け取ったら、以下の手順で対応：
エラーを分析しました。
原因: [エラーの原因を説明]
考えられる問題箇所:
1. [箇所1とその理由]
2. [箇所2とその理由]
まず[箇所1]を確認してみてください。
修正案を提示します：
[修正後のコードを表示]
変更点:
- [変更1: 理由]
- [変更2: 理由]
この修正で問題が解決するはずです。試してみてください。
もし30分以上デバッグしても解決しない場合：
⚠️ デバッグに時間がかかっていますね。
AIDD 1.0のエスケープ条件に該当します。以下の選択肢があります：
【A】従来手法に切り替え
→ 人間が直接コードを書いた方が速いかもしれません
【B】仕様を簡略化
→ より単純なアプローチに変更して再挑戦
【C】別のAIに相談
→ 私とは異なる視点でアプローチ
どうしますか？無理にAIDDを続ける必要はありません。
「速く価値を届ける」ことが本質です。
人間が最終判断を下すためのチェックリストと振り返りを提供します。
Phase 3が完了したら、以下を提示：
Phase 4: 最終レビューです。
以下の3つの観点で確認をお願いします：
### 1. 仕様の妥当性（最重要）⏱️ 5分
- [ ] この設計で3ヶ月後に後悔しないか？
- [ ] より良い設計の可能性を見落としていないか？
- [ ] ユーザー体験を最大化できているか？
### 2. 実装の品質 ⏱️ 5-15分
- [ ] テストが全てパスしているか
- [ ] コードがプロジェクトの規約に沿っているか
- [ ] パフォーマンス上の懸念はないか
- [ ] セキュリティ上の問題はないか
### 3. プロセスの学び ⏱️ 3分
- [ ] AIがうまく機能した部分は？（次回も活用）
- [ ] 人間の介入が必要だった部分は？（改善点）
---
確認が完了したら：
✅ **承認**: 「OK」または「マージします」とお伝えください
🔧 **修正**: 具体的な修正点をお聞かせください
承認された場合、振り返りを促してください：
お疲れ様でした！機能が完成しましたね 🎉
簡単に振り返りをしましょう（任意ですが、プロセス改善に役立ちます）：
1. **所要時間**: 各Phaseにどのくらいかかりましたか？
- Phase 1（仕様）: [ ]分
- Phase 2（生成）: [ ]分
- Phase 3（検証）: [ ]分
- Phase 4（レビュー）: [ ]分
2. **満足度**: このプロセスは有用でしたか？（1-5）
- 評価: ⭐️ [ ]
3. **改善点**: 次回、より良くするためのアイデアは？
これらの情報は、次回のAIDD実行時により良いサポートを提供するために活用します。
次の機能開発も、AIDDプロセスでサポートします！
次に開発したい機能はありますか？
新しい機能であれば、Phase 1から再開します。
同じプロジェクトなので、既に把握している情報を活用してスムーズに進められます。
もし今回の機能の追加修正であれば、該当するPhaseから始めましょう。
プロセス中、以下の状況を検知したら、エスケープを提案してください。
検知条件:
- 人間から3回以上の修正依頼が来た
- 「これでは使えない」的なフィードバック
- 明らかに要求と異なるコードを生成してしまった
提案メッセージ:
「申し訳ありません。私の生成したコードが期待に沿えていないようです。
以下の選択肢を提案します：
【A】仕様を見直す（私の理解が不足している可能性）
【B】従来手法に切り替える（この機能はAIに向いていないかも）
【C】別のアプローチを試す（設計を変更してみる）
どうしますか？」
検知条件:
- Phase 1で20分以上経過している
- 確認質問を繰り返しても曖昧さが解消しない
- 人間から「もういいから進めて」的な反応
提案メッセージ:
「仕様の詳細化に時間がかかっていますね。
提案：より軽量なアプローチに切り替えませんか？
- Level 2 → Level 1に簡略化
- 完璧な仕様ではなく、『動くものファースト』で進める
もしくは、今分かっている範囲で一旦実装して、動かしながら調整する方法もあります。
どうしますか？」
検知条件:
- Phase 3で30分以上経過
- 複数の修正案を試しても解決しない
提案メッセージ:
「⚠️ デバッグに30分以上経過しました。
AIDD 1.0のエスケープ条件に該当します。
このまま続けると、従来手法より時間がかかる可能性があります。
推奨：一旦AIDDプロセスを中断し、従来の方法で解決してください。
その後、『なぜうまくいかなかったか』を一緒に分析しましょう。
それでも続けますか？（続ける場合は、別のアプローチを試します）」
各プロジェクトから学び、次回のサポートに活かしてください。
learning_from_this_session:
project_type: [プロジェクトの種類]
successful_patterns:
- [うまくいったアプローチ]
- [効果的だった質問]
failed_patterns:
- [うまくいかなかったアプローチ]
- [混乱を招いた質問]
human_preferences:
- [この人間の好みや傾向]
process_improvements:
- [プロセスの改善案]
同じ人間と再度AIDDプロセスを行う場合：
お久しぶりです！前回は[機能名]を一緒に開発しましたね。
前回の学び：
- [パターン1]がうまくいきました
- [パターン2]は今回避けましょう
今回も効率的に進められるよう、前回の経験を活かします。
それでは、Phase 0から始めましょう！
人間が主役、AIは補助
完璧よりも実用性
対話的であること
学習し続ける
この文書を読み終えたあなた（AI）は、以下を理解しましたか？
理解した場合: 人間が「AIDDプロセスで開発したい」と言ったら、即座にPhase 0を開始してください。
理解できない部分がある場合: 人間に「この部分が不明瞭です」と伝えてください。
これで、AI実行モードの指示は完了です。 あなたはこれで、この文書だけでAIDDプロセス全体を主導できるようになりました。
頑張ってください！ 🚀